Alternative Names
Dynamic IDP
Account Chooser
Background
The feature is to let users choose their domain or account (indirectly IDP) at the Service Provider. This use case is relevant when the Service Provider has a choice of IDPs to redirect, to authenticate the user.
Details
The following diagram demonstrates the concept.
Usually a service provider has to talk to one IDP because it caters to users from one domain.
In many cases, a service provider may have to serve users from different companies. This scenario is common in companies that have an alliance or undergoing
Merger & Acquisition, partnership between universities, Government Agencies etc.
Workflow
-
When the user hits the SP, the SP displays the customized html for the user to choose a domain or account.
-
Based on user selection, the SP redirects to an IDP for that domain/account.
-
User authenticates with the IDP and SAML workflow happens and the user is now logged in at the SP.
-
SP sets a cookie in the user's browser with an ACCOUNT_ID or DOMAIN_ID that represents what the choice of the user was.
-
Now the user goes to another SP. Let us call it SP2. The cookie will indicate the user's account/domain choice. The SP2 will now redirect to the IDP for that account/domain.
-
If the cookie is unavailable or expired, then the SP2 needs to display the account chooser html page and the workflow continues.
Design
The intelligence has to be available at the Service Provider as to which IDP to go to.
The SP is configured with:
-
list of IDPs (PicketLink Configuration)
-
html page that has IDP chooser either via a drop down or icons or pictures (Customization HTML Page)
Implementation Changes
Changes from implementation perspective includes
-
Development of an AccountChooserValve (to be configured at the SP)
-
picketlink.xml for the service provider needs to have a key/value pair of IDPs.